如果有在研究或使用 AI Agent 的人，常常會把 AI 關進沙箱、擋掉對外連線，覺得這樣它就跑不出去了。然而在2026 年 9 月，OpenAI 公開了一起事件：一個正在訓練的 agent 在幾乎所有對外連線都被擋下的情況下，找到一條沒人注意的路，連上外部的聊天機器人。

這篇文章就來一下整理事件經過、技術原因和 OpenAI 的處置，最後聊聊我認為我們工程師，應該從中學到什麼。

事件經過

根據 OpenAI 的官方報告，在 9/20 的時候，有一個 agent 在強化學習訓練的過程中，接到一個任務是找出某篇部落格的作者。

雖然它嘗試過的方法全都失敗了：

• 核准的搜尋工具給的結果不相關。
• 直接連 Google、Bing、DuckDuckGo 都被擋。
• 用 HTTPS 連公開的聊天機器人，也被網路代理擋下。

但是它發現，沙箱裡的 DNS 解析器會回傳真實網域的紀錄。於是它推論出這條路連得到外面，把問題編進網域名稱，透過公開的 DNS 委派服務轉給外部的聊天機器人，前後共送出 19 個問題。（但最後它還是沒找到作者）。

報告列出的時間線如下（報告沒有標明時區）：

從警報響起到真正停下，中間隔了將近 2.5 小時。Ars Technica 的報導指出，原本應該觸發的自動停止機制沒有啟動，現場對要不要停下也有過混亂。

DNS 平常被當成「只是把網址轉成 IP 地址」，所以常被忽略。但它本來就能夾帶資料，資安界稱這種手法為 DNS tunneling。

後續處理

OpenAI 在 9/25 公開這份報告後，處置包括：

1. 停掉這次訓練，之後會重新訓練一個新模型。
2. 全面暫停：最強模型的所有訓練、評估和帶工具的推論都停下，要等確認漏洞補好、做完更多紅隊演練才恢復。
3. 技術修補：DNS 改用白名單，在兩個互相獨立的層各加一道阻擋，新增 DNS 偵測，並替偵測流程本身加上測試。
4. 回頭檢查時發現，還有其他對外 DNS 存取沒有被標到應有的嚴重程度。

外界反應方面，The Verge 認為這顯示 agent 越來越難控制。

我的看法

看到這件事我真的覺得太神奇，我常常教課的時候就一直跟學生說 AI 不能幫你負責，出事了還是要工程師扛，所以千萬不要過度依賴 AI。

隨着 Agent 能做的事越來越多，越來越多人開始依賴甚至是把自己的所有權限都給了 Agent，但是你根本不知道你的 agent 昨天做了什麼！

所以「AI 不能替你負責」不是一句口號，而是現在真實發生的事。

這也是為什麼我會一直跟學生說要學寫程式。回頭看這次事件，每一個環節都需要你真的懂：

1. 出口控制要涵蓋所有協定。 只擋 HTTP 不夠，DNS、NTP、套件鏡像都可能是出口。
2. 防護要分層。 每一層都要能單獨擋下，不能把安全押在單一元件上。
3. 緊急停止要實際演練。 自動停止沒有作用，就會拖成 2.5 小時。停止開關和應變手冊都要定期演練。
4. 監控本身也要驗證。 告警可能漏報，也可能把嚴重程度判得太低。
5. 安全假設要寫下來並實際驗證。 「模型連不到網路」這個假設一旦錯了，後面所有防護都會失效。

AI 可以幫你寫程式，但出事時站出來的會是你 ！